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[57] ABSTRACT 

A system for compiling and managing screen images on 
a stack or data base with attached fields, and application 
program objects. The system lets users compile pro- 
grams from screen images and their attached objects, 
which if executed after the screen image and object 
parameters have been changed, will translate the same 
screen image with the same objects attached in the same 
places. This allows maintaining multiple formats each 
with different application for the same stack. The sys- 
tem can be used to (a) edit screen formats in the pro- 
gram's script language, (b) manage alternative user 
interfaces for a data base or stack, (c) provide multiple 
formats and application interfaces for the same data 
base, (d) have multiple user interfaces for the same data 
base depending on users sophistication, (e) solve the 
system update installation problem, and (f) allow copy- 
ing user interface including functional capability from 
one stack and installing it in another. 

20 Claims, 17 Drawing Sheets 
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Tom Polhous is a detective inthe Maltese Falcon. 

The movie starred Humphery Bogart and Mary Aster was directed 

by John Huston. 
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Create card and copy Background Picture to it 
SET Card ID into GENEPICTID 



OUTPUT HANDLER (GENE1NF0) 



OUTPUT HANDLER( REVERT GENE) 



COMPILEHANDLER (REYERTBUTT0N5) 



COMPILEHANDLER (REVERTFI ELDS) 



OUTPUT HANDLER( REVERT CONFIGURATION) 



c 



DONE 



Figure 8 
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1 2 

although the invention is not so limited and could be 

INTERFACE AND APPLICATION used with other data bases. HyperCard is based on the 

DEVELOPMENT MANAGEMENT SYSTEM metaphor of (index) cards in stacks where the user is 

BASED ON A GENE METAPHOR able to see a single card at a time. Each screen consists 

5 of a background with is common for all cards in the 

This is a continuation of Ser. No. 07/461,016, filed on stack and a card portion which is different for each 

Jan. 4, 1990, now abandoned. card. Both the card and background portion consist of 

BACKGROUND OF THE INVENTION ^ ^ e the a la £ rs ° f transparencies used to create 

animated movies. The bottom background layer con- 
An important aspect of making computers powerful 10 tains a visual image which can be created with Hyper- 
is to make it easy for users and application developers to Card's paint commands. Each higher background layer 
make new and custom applications. A conceptual contains a single object comprising either a field with 
model that supports this and necessary display mecha- text information or a "button" with a name, image or 
nisms was described in two prior patents U.S. Pat. No. tnat> wnen activated, executes an application pro- 
4,486,857 and U.S. Pat. No. 4,736,308. The inventions 15 or "script" associated with the button and is writ- 
described therein are implemented in a program called ten m a prop rietary Apple language called HyperTalk. 
Zoomracks. Zoomracks is a trademark of Quickview HyperTalk is a trademark of Apple Computer. Hyper- 
Systems and is available from Quickview Systems at 146 Ta]k is m object orien ted programming language con- 
Main Street, Los Altos, CA. 94022. U.S. Pat. No. s i stm g of modules that are called "handlers" which are 
4,486,857 describes a system that displays portions of a 20 similar tQ subroutines m function . while these buttons 
record truncating the fields to fit the screen size. In ^ fie]ds ^ over , QI M of buttons or fields on 
parttcular the records which may be referred to as }ower t arencieS; usuall flelds and buttons do not 
screens or cards, each may contain multiple fields ^ each other ^ arg z00med 
where the fields are truncated so an entire card can be Qn £ Qf ^ back d , m laced a similar 
viewed on the screen at once with only parts of individ- 25 Qf ^ for ^ fa particular stack. While a 
ual fields showing. Typically there would be several , J , r , . . , f U( , M „ 
, / « v . a. i / £*\ \ *t*i_ t card can have as many or more buttons and fields as a 
cards (or records) in a stack (or file). There is a mecha- A . , . , , J . - u , ^ r , A 

, , , < - j- j i r 1.4 *^ :* stack background does, it often has no buttons or fields, 

msm to select and zoom any individual field to show it * * f ' , A A , A , , 

in its entirely even if it is longer then the whole screen. As J he u f r goe * f ™ ° ne ^ to «<J«. * he 

U.S. Pat. No. 4,736,308 is an improvement that allows 30 Portion changes but the background portion stays the 
the user to view portions of many such cards and lets «*■ background field is a special case m that its 
users organize and view their cards in overlayed groups ™ ten * < text ) chan ^ es but lts form ( locatlon ' slze > ^ 
or stacks so that they appear to be in racks like time sta y? ^ me * ^ , t . 
cards at at time clock. While not described in the pa- ™ e fields and bu * tons ™ ob f cts that are attached 
tents, the Zoomracks program allows users to create 35 on the cards ™ d backgrounds m layers have properties 
macros and do simple programming which, combined ?r attnbutes most of which specify how they look, 
with the patented technology, enables users to do a Object, button, field and property are terms of art 
wide variety of applications. The invention described which have technical meanings; however, the use of 
herein builds on the inventions described in U.S. Pat. such terms is for lustration purposes only and does not 
Nos. 4,486,857 and 4,736,308. 40 limit the sco P e of this invention. Fields and button prop- 
Most data base programs are based on computer con- erties include style (opaque, rectangle, scrolling, or 
cepts of computer files and records and are designed for transparent), width (measured in pixels or number of 
keeping information and creating reports. More sophis- dots )> height(pixels), top(pixels), and left (pixels), text- 
ticated data base management programs are relational in font (Geneva, Helvetica), teststyle (bold, plain, italic), 
that they permit the user to relate two or more separate 45 ^ textsize (pixels). Changing a property changes how 
files that have a common field in each of the various the field or button is displayed on the screen. Thus 
records. changing a text style from bold to italic displays the 
HyperCard, which is available from Apple Com- same text for that object in italic rather than bold, or 
puter, Inc, 20525 Mariani Ave, Cupertino, CA., 95014, changing height changes the height of the object. Most 
uses concepts in U.S. Pat. No. 4,486,857. HyperCard is 50 properties can be changed graphically with HyperCard 
a trademark of Apple Computer. Zoomracks and Hy- commands; all properties can be changed by a single 
perCard approach data bases differently from conven- HyperTalk programming language statement. An im- 
tional data bases. They are designed as flexible plat- portant property is ^'visible" which specifies whether or 
forms that support multiple applications within a com- not an object is visible on the screen, 
mon metaphor. The variety of applications they support 55 In essence a HyperCard stack is an application with 
are much wider than conventional data base applica- the data provided in the fields and the functional capa- 
tions and include word processing, hypertext and a bility provided in the "button" scripts. The applications 
variety of other applications not normally addressed by are modularly segmented into button scripts. To exe- 
data base programs. The new approach brings the famil- cute a function the user selects the appropriate button 
iarity of index cards in stacks and racks, where a rack or 60 and executes it. Typically, a button has a graphic icon 
stack is analogous to a file, along with the power to although it may use a text name. Buttons, which were 
store large amounts of information in fields and zoom known before HyperCard, provide an alternative to 
and scroll it. menus, commands, or macros as a mechanism for initiat- 

HyperCard advanced the state of the art over Zoom- ing actions, 
racks. The invention described herein is an advance 65 Users and developers can build applications by put- 
over HyperCard. Since the system described here is ting objects on the backgrounds and can modify the 
implemented on HyperCard which is widely available, applications by changing the objects properties and 
the focus of the description is its use with HyperCard, scripts. HyperCard makes it easier for people to de- 
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velop and prototype applications and try out different 
user interfaces. 

HyperCard and other current technologies provide a 
framework in which users can develop and modify 
programs if they are reasonably straightforward. How- 5 
ever, richer and more complicated applications that 
consist of functions (or tools) have potential interactions 
that grow exponentially in their complexity and are thus 
more difficult to develop and maintain. It normally 
requires an experienced programmer to create and mod- 10 
ify such programs. This invention provides a frame- 
work which lets developers and users organize applica- 
tions into fields and buttons and provides a mechanism 
to manage the user interface formats that these applica- 
tions present on the screen. The invention brings new 15 
power to both experienced and inexperienced program- 
mers alike in that they can develop, modify, and up- 
grade more sophisticated applications. 

Computers programs that are based on metaphors 
have proven useful as being easier to understand and 20 
use. The spreadsheet metaphor popularized by VisiCalc 
and the desktop metaphor invented by Xerox and popu- 
larized on the Macintosh are examples of these. The 
invention described here is largely based on the meta- 
phor of genes. Genes which are the basis of all life have 25 
the following similarities to the metaphor described: 

(a) they encode form(at) information, 

(b) they encode information efficiently in that a small 
change can have global effects, 

(c) they can be cloned to create copies of themselves, 30 

(d) they can be translating or turned on which causes 
a specific form(at) (in the case of living genes, protein) 
to be constructed from existing elements (objects or 
amino acids). 

(e) The information encoded can continue to evolve 35 
supporting more complex form(at)s. New information 
can be added to a genome without interfering with the 
existing genes. They support an evolutionary rather 
than a revolutionary approach to design change. 

(f) They allow the transmission of of genetic informa- 40 
tion from one organism to another (conjugation) and 
the creation of descendant organisms which contain 
genetic information from two parents. 

(g) Genetic engineering allows changing a gene's 
encoding to change the resulting form(at), 45 

(h) Recombination is inserting genetic information 
from one organism into another. 

The last two of the above processes are artificial, the 
rest are natural. All of these processes are supported by 
analogy in the invention described here. 50 

SUMMARY OF THE INVENTION 

In an interactive display system which includes a data 
entry display screen, an input device, a processor, and a 
data storage device; is a program to control the visual 55 
display or format of at least one or more objects on one 
or more screens where the objects have defined proper- 
ties. The program includes specifications for defining 
object properties both as they exist on the screen and in 
a computer language or other form. It includes a trans- 60 
lator to convert the object properties specifications 
associated with the at least one object in the at least one 
screen into specifications in the computer language or 
second form called a gene script. It also includes the 
ability to translate the specifications of one or more 65 
objects from the gene script back to the visual screen 
image. It includes the ability to manage multiple gene 
scripts specifying different formats for the same stack, 



the ability to edit formats as gene scripts, and the ability 
to selectively translate the gene into the screen format 
whose objects properties are specified by a gene script. 
Finally it includes the ability to copy or port gene 
scripts from one stack to another and inject part or all of 
the ported format to the new stack. 

BRIEF DESCRIPTION OF THE DRAWINGS 

The foregoing and other uses of this invention, its 
various features thereof, as well as the invention itself 
may be better understood from the following descrip- 
tion, when read together with the accompanying draw- 
ings:" 

FIG. 1 shows the environment in which the invention 
works. 

FIG. 2a shows the name and address format for stack 
A with only visible objects showing. 

FIG. lb shows shows the FIG. 2a format with invisi- 
ble objects also showing. 

FIG. 2c shows shows FIG. 2a with 4 gene buttons 
displayed. 

FIG. 2i d shows the background graphic for the for- 
mat shown in FIG. 2a 

FIG. 3a shows a print label format for stack A with 
only visible objects showing. 

FIG. 3b shows shows the FIG. 3a format with invisi- 
ble objects also showing. 

FIG. 4a shows a mail merge format for stack A with 
only visible objects showing. 

FIG. 4b shows shows the FIG. 4a format with invisi- 
ble objects also showing. 

FIG. 5 is a Social Security format for stack B. 

FIG. 6 shows Stack A after the social security format 
has been ported to it. 

FIG. la shows the name and address format for stack 
A after the ported button and field have been made 
visible. 

FIG. lb shows figure 7a, a new format created by 

editing with HyperCard. 
FIG. 8 is a flowchart of the KEEP BACKGROUND 

FORMAT command 
FIG. 9 is a flowchart of COMPILEHANDLER 
FIG. 10 is a flowchart of the NEXTOBJ hander 
FIG. 11 is a flowchart of CONVERT PORTED 

GENE 

DESCRIPTION OF THE PREFERRED 
EMBODIMENT 

Referring now to FIG. 1, the environment of this 
invention is illustrated. A display device 510 is shown 
along with a an input device or keyboard 512. Associ- 
ated with the keyboard 512 and display device 510 is a 
processor or computer 514. An output device 515 in the 
form of a printer permits the user to obtain hard copy 
from the processor 514 in a manner well known in the 
art. One other item important to the understanding of 
the invention is mouse 516. A mouse, which is well 
known in the art, permits the user to manipulate the 
cursor on the display device 510 and to initiate by 
"clicking" the button 518 located on the mouse. It 
should be understood that the mouse is not necessary to 
the invention although in certain circumstances it pro- 
vides faster input of information to processor 514. Fi- 
nally a telephone 520 may be included with the system 
500. In one illustration of the invention, the program 
includes the capability to dial phone numbers by acti- 
vating an icon on the screen with the button on the 
mouse. This invention has been developed using an 
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Apple Macintosh SE/30 computer configured as indi- The DIAL OUT script shown in Table 1 takes a text 

cated in FIG. 1. Macintosh computers are available string from the selected field if one is selected at line 

from Apple Computer, Inc at 20525 Mariani Ave. Cu- 400, or the field PHONE 54v if it is not empty at line 

pertino, CA. 95014. The software disclosed herein as 402, or from the user by asking for a phone number at 

the invention is built on the HyperCard software avail- 5 line 404. It then calls a handler that converts the text 

able for use on the Apple Macintosh. This software is string to a series of tones and outputs them an external 

also available from Apple Computer Inc. port to which a phone is connected at line 406. 

In the drawings, reference will be made to visible HyperCard only displays those object whose visible 

fields or buttons in the drawings by using a number property is true. FIG. lb shows the same format shown 

followed by the letter"v" Statements in the script or 10 FIG. 2a for stack A except that invisible fields and 

program that give properties to the same fields or but- buttons, whose visible property is false in FIG. 2a, are 

tons in the drawings are referred to by the correspond- also shown in addition to the background graphic and 

ing number followed by the letter "s" The pertinent fields' and buttons shown in FIG. 2a, The invisible fields 

parts of these scripts or programs are included in this are PROTO FROM 68v, PROTO DEAR NAME70v, 

specification as tables. These scripts are written in the 15 and PROTO LETTER 72 v and the invisible buttons are 

Apple Computer language HyperTalk. PRINT LABEL 76v, CREATE LETTER 84v, GO 

Having set the environment, FIG. 2a shows an "ad- PROTO LETTER 86v and PRINT LETTER 87v. 

dress and phone" format for a stack as might appear on FIG. 2b shows that a background such as is shown in 

display device 510. This is stack A for identification FIG. 2a can contain several invisible objects and but- 

purposes. This format consists of a background graphic, 20 tons. 

fields and buttons. The background graphic contains FIG. 2c shows the same format for stack A as is 

the names of the fields (NAME, COMPANY etc.) writ- shown in FIG. 2a except that gene buttons 88 are shown 

ten on them. The background graphic could be any in the lower left corner. An object of this invention is to 

picture and need not have names on them as can be seen create such gene buttons with scripts that encode for- 

in the background graphic in FIG. 2d. 25 mats. Selecting a gene with mouse 516 and then depress- 

The format has several visible fields: NAME 50v, ing mouse button 518 will list a name of the gene button 

COMPANY 52v, PHONE 54v, TITLE 56v, AD- which is the format it encodes and a menu of options, 

DRESS1 58v, ADDRESS2 60v, ZIP 62v, DEAR- one of which, TRANSLATE GENE which if executed 

NAME 64v and NOTES 66 v. In HyperCard these fields translates the gene into its encoded format. These gene 

contain text information only although they could con- 30 buttons will be discussed in detail later, 

tain picture, sound or other information including FIG. 3a shows the same card from stack A as FIG. 2a 

mixed information such as mixed graphics and text. but with a different "print label" format. It has a differ- 

The format also includes the button DIAL OUT 74v. ent background graphic from FIG. 2a; the field names 

This button is represented as an an icon or graphic have been moved and the names of now invisible fields 

image of a telephone and has associated with it an exe- 35 do not appear. Many of the same button and field ob- 

cutable program or script. Not all buttons have such jects are used, but they have different properties. The 

graphic icons. The DIAL OUT 74v, when activated by field objects NAME 50v, TITLE 56v, ADDRESS! 58v, 

appropriate "clicking" of mouse button 518 initiates the ADDRESS2 60v, and ZIP 62v, and the button object 

HyperTalk script shown in table 1. NEXT CARD 70v are all objects that were shown in 

TABLE 1 40 the format m FIG - 2*. Other objects like PHONE 54v 

and NOTES 66v are not used in this format and are 

° n Te^thTsckction - 400 invisible. This format is designed for printing labels and 

if it is empty then get first line of field "Phone" - 402 the button PRINT LABEL 76v, which was invisible in 

if it is empty then ask "Dial what number?" —404 FIG. 2a is visible in this format and has associated with 

if it is not empty then dial it - 406 45 it a script that prints a label. The locations of the visible 

end mouseUp fldds haye changed ^ F jq ^ frQm what they 

were in FIG. 2a. The background graphic with the 

A button could contain more complex program names of the fields is different in FIG. 2a from what is 

scripts. In HyperCard this script is executed by manipu- in FIG. 3a; FIG. 3b shows the same format as shown in 

lating the cursor on display device 510 with mouse 516 50 FIG. 3a but with the invisible field and button objects 

so that the cursor is imposed on phone button 74v and from the card also appearing. These the fields are 

then pressing the mouse button 518. (It is to be under- PHONE 54v, DEARNAME 64v, NOTES 66v and the 

stood that button 518 on mouse 516 is in fact a physical buttons DIAL OUT 74v, CREATE PROTO LETTER 

button which can be pressed to accomplish the figura- 84v, GO PROTO LETTER 86v, and PRINT LETTER 

tive pushing of the "button" displayed on the display 55 87v. 

device 510.) Other methods of activating a button could FIG. 4a shows the same card as in FIGS. 2a and 3a. 
be used, and other methods of execution than buttons It contains a third "mail merge" format for stack A. 
could be used. For example, one could use menu objects This format is designed for writing letters and doing 
which contain menu commands and scripts instead of mail merge and its fields are arranged as they would 
button objects. The DIAL OUT program is simple and 60 appear in a letter. Its background graphic is white and 
is included with HyperCard. In normal use it takes a does not have field names so it looks like a letter. It uses 
text string from the field PHONE 54v and calls a routine the field NAME 50v, TITLE 56v, ADDRESS1 58v, 
that converts the text string to a series of tones and ADDRESS2 60v, ZIP 62v, and the button NEXT 
outputs them to an external port to which a phone 520 CARD 70v, as well as objects that were not used and 
is connected. The background could have other buttons 65 thus were not visible in earlier formats: the fields 
with other scripts with other application functions and PROTOFROM 68v, PROTO LETTER 72v and the 
the format shown in FIG. 2a has a second such button, buttons CREATE LETTER 84v, GO PROTO LET- 
DOWN 70v which goes to the next card in the stack. TER 86v, and PRINT LETTER 87v. FIG. 4b shows 
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the same format as FIG. 4a with the invisible objects 
made visible: the fields PHONE 54v, NOTES 66v and 
the buttons PRINT LABEL 76v and DIAL OUT 74v. 

HyperCard users can change the format of a stack A 
from FIG. 2a to FIG. 3a, or FIG. 4a to FIG. la, or 5 
make other format changes by using HyperCard's 
FIELD and BUTTON commands to move and resize 
the field and button objects on the background and 
change other field and button properties. Some object 
properties such as VISIBLE, can be changed only with 10 
a HyperTalk statement. For example, "SET VISIBLE 
OF BKGND FIELD "DIAL OUT" TO FALSE" 
makes the DIAL OUT field invisible. Once the user has 
a format he wants, the invention described here pro- 
vides a way to save it so he can restore to that format in 15 
the future. This capability is not available in the Hyper- 
card program. The invention also provides a way to 
save many different saved formats for the same stack 
such as the three formats for stack A shown in FIGS., 
2a, 3a and 4a so each can be selectively restored when 20 
desired. 



8 



Format of Gene Scripts 

A command called KEEP BACKGROUND FOR- 
MAT compiles a gene script that specifies the proper- 
ties of all objects on the background in a form that, 
when executed, restores the properties of those objects. 
Thus a user can create the format shown in FIG. la 
using standard HyperCard tools and save it in a gene 
script with the KEEP BACKGROUND FORMAT 
command; then change the background to FIG. 3a 
using standard HyperCard tools and saves it in the new 
format in a second gene script with another KEEP 
BACKGROUND FORMAT command; and then 
change the background to FIG. 4a using standard Hy- 
perCard tools and create a third gene script with another 
KEEP BACKGROUND FORMAT command. Now, 
executing one of the three gene scripts restores the 
associated background format for that stack. 

The KEEP BACKGROUND FORMAT command 
puts the script in a background button called TRANS- 
LATE BACKGROUND which is the left button of the 
four buttons 88 in FIG. 2c. Other commands let the user 
clone and name the genes which specify the formats. 
The other three of the four gene buttons 88 on the bot- 
tom right of FIG. 2c specify the three formats for 2a, 3a, 
and 4a. 

While the major objective of the invention is to save 
the properties of buttons and fields, it also to save the 
graphic picture in the background and configuration 
variables. 

The KEEP BACKGROUND FORMAT command 
works as is shown in the flowchart in FIG. 8. First it 
creates a new card in the stack and copies the back- 
ground graphic to that card 102 and stores that ID in 
the global variable GENEPICTID 103, then it outputs 
a handler GENEINFO 104, then handler TRANS- 
LATEGENE 106, then handler TRANSLATEBUT- 
TONS 108, then handler TRANSLATEFIELDS 110 
and then the handler TRANSLATECONFIGURA- 
TION 112. 

TABLE 2 

On Genelnfo — 2 

Put "HD 40:Hracks2:Qnames" into GENERACK - 4 

put "card id 8337" into GENEPICTID - 6 
end Genelnfo — 8 



25 



30 



35 



40 



45 



50 



55 



60 



65 



Table 2 contains the handler (or subroutine) called 
GENEINFO beginning with ON GENEINFO 2 and 
ending with END GENEINFO 8. All handlers begin 
and end similarly. This handler defines global variables 
and information about the state when the gene script 
was generated. Statement 4 of this handler specifies the 
name of the stack (file) the gene was generated from. If 
the gene is copied to another stack, this name can be 
used to recognize the gene as foreign. Installing foreign 
genes in stacks is described later. Statement 6 defines 
the global GENEPICTID as the ID of the card that 
contains the saved background picture. 

TABLE 3 

on TRANSLATEGENE — 2 

GENEINFO — 9 

TRANSLATEFIELDS - 10 

TRANSLATEBUTTONS — 12 

TRANSLATEPICTURE — 14 

TRANSLATECONFIGURATION" — 16 
end TRANSLATEGENE — 8 



Table 3 contains the handler, TRANSLATEGENE 
which translates the complete format from the gene. It 
executes statement 9 to define global variables, state- 
ment 10 to translate the field formats, statement 12 to 
translate the button formats, statement 14 to translate 
the background picture and statement 16 to translate the 
stack configuration. With the exception of TRAN- 
SLATEPICTURE, each of these handlers is compiled 
in the gene script and will be described shortly. 

TRANSLATEPICTURE just copies the graphic 
image from the card specified by the global variable 
PICTURED onto the background. An examination of 
the cards in la, 3a, and 4a shows that while the back- 
ground texture is the same for all, the field names which 
are part of the background graphic image are different 
for each. It is these images that are restored with the 
TRANSLATEPICTURE handler. 

TRANSLATEBUTTON and TRANSLATE- 
FIELD are identical in concept, one translating buttons 
and the other fields. Both of these scripts are compiled 
from the properties of their objects. 

The art of constructing Compilers is well understood 
given specification of the input and output languages. 
The input language is the arrangement of buttons or 
fields on the screens, the output is the gene scripts de- 
scribed here. The complete script for the gene format 
shown in FIG. 2a is presented in Tables 2,3,4,6,7, 8 and 
9. While not necessary, scripts written in a host lan- 
guage enable users who are familiar with that language 
to use its capabilities. 

There are many different kinds of scripts that could 
be compiled and would restore the format. The simplest 
and most obvious compiler would output N times P 
statements where N is the number of objects and P is the 
number of properties or attributes of the object. There 
would be P statements for each of N objects, each state- 
ment specifying a different property for a its object. The 
preferred embodiment compiles scripts that specify 
property changes only, and thus are shorter, less error 
prone and have other desirable properties. 

Scripts for Translating to Button and Field Formats 

The TRANSLATEFIELDS and TRAN- 
SLATEBUTTONS handlers differ only in that one 
translates the properties of the fields, the other of the 
buttons. The basic concept behind the scripts in Tables 
4, 6, 7 and 8 is that the compiled script consists of alter- 
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nate groups of statements which (a) redefine the current 
value of the properties to be assigned to field or button 
objects, and (b) "nextobj" statements which assign to a 
specific object the then current values of those proper- 
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It is preferable that GENESTART FLD 24 follow 
the statements which initialize the parameters 18. This 
allows the interception of the GENESTART handler 
to override the initial property specifications. 

TABLE 4 

on TRANSLATEFIELDS — 2 
set visible of target to true — 18 
set textfont of target to Geneva — 18 
set textstyle of target to plain — 18 
set textalign of target to left — 18 
set textsize of target to 12 — 18 
set textheight of target to 16 — 18 
set style of target to rectangle — 18 
set width of target to 167 — 18 
set height of target to 16 — 18 
set top of target to 59 — 18 
set left of target to 14 — 18 
GeneStart "Fid" — 24 

nextObj Show, "bg fid id 1162", "NAME" -1 "14,59,181,75" —50 s 
set width of target to 1 19 — 28 
put 167 into XDELTA — 30 
put 0 into YDELTA — 32 
nextObj Show, "bg fid id 1197" 
set width of target to 173 — 28 
put 119 into XDELTA — 30 
nextObj Show, "bg fid id 1195" 
set width of target to 225 — 28 
put - 150 into XDELTA — 30 
put 16 into YDELTA — 32 
nextObj Show, "bg fid id 1196" 
put 0 into XDELTA — 30 
nextObj Show, "bg fid id 1198" 
set width of target to 203 — 28 
nextObj Show, "bg fid id 1199" 
set width of target to 120 ™ 28 
put 202 into XDELTA— 30 
put 0 into YDELTA— 32 
nextObj Show, "bg fid id 1366" 
set width of target to 215 — 28 
put -202 into XDELTA— 30 
put 16 into YDELTA— 32 
nextObj Show, "bg fid id 1200" 
set style of target to scrolling - 
set width of target to 445 — 28 
et height of target to 112 — 28 
put - 122 into XDELTA— 30 
put 32 into YDELTA — 32 
nextObj Show, "bg fid id 1201" 
[code from Table 6 would be inserted here] — 20 
GeneDone Hide -Unspecified Objects Hide,Show or Asls 
end TRANSLATEFIELDS — 8 



"COMPANY" -2 "181,59,300,75" — 52s 



"PHONE" -3 "300,59,473,75" — 54s 



"TITLE" 



"150,75,375,91" — 56s 



"ADDRESS 1" -5 "150,91,435,107" — 58s 
"ADDRESS2" -6 "150,107,393,123" — 60s 

"Zip" -7 "393,107,472,123" - 62s 



, "DEARNAME" -8 ' 
•28 



150,123,365,139"- 64s 



"NOTES" -9 "28,155,473,267" - 66s 



• 36 



ties, some of which have just been changed. Table 4 45 
shows the handler that translates the properties of the 
fields to that shown in FIG. 2a. Line 2 and line 8 define 
the beginning and ending of the handler. Lines 18 define 
the initial current value of all the field properties. The 
word "target" appearing in these and other statements 50 
is an an object which maintains the current standard 
values of properties. In the current implementation the 
reversion scripts run in the gene button which is the 
target and takes on the current properties. However, 
the properties could be saved in global variables or 55 
some other way. 

GENESTART FLD 24 calls the handler GENES- 
TART which initializes the format for all the fields (or 
if its argument is BTN, for all the buttons). Its task is to 
do the initialization. In particularly it must make all the 60 
background field objects are invisible so that any ob- 
jects whose properties are not specified in the script will 
not appear in the background. This is important because 
new objects added after the gene script was created 
should not be visible after the gene is translated. This 65 
routine initializes the global NEXTOBJECTNUMBER 
to 1 which specifies number property of the next object 
to be output. 



The lines 18 in Table 4 define the initial "current" 
properties which will be given to the object specified by 
the first NEXTOBJ statement in line 50s. Lines 28, 30 
and 32 redefine the current values of some properties 
for future NEXTOBJ statements. Line 50s assign the 
initial current properties to "bg fid id 1162", statement 
52s assigns the then current properties to "bg fid id 
1197", and statements 54s, 56s, 68s,58s, 60s, 62, 64s, and 
66s assign the then current properties to the objects 
specified in the statement, lines 28,30 and 32 preceding 
each NEXTOBJ statement. 

The use of "current" properties which are incremen- 
tally changed and are assigned to objects is a useful but 
not necessary feature of the invention. It is valuable 
because where successive objects have the same proper- 
ties — which is frequently the case — then properties are 
specified once making the script shorter, easier to read, 
and easier to edit. Also, a differential specifications 
bring attention to differences between object properties 
which may be errors. For example successive objects 
may have widths of 18, 19, 17, 19, and 20. In this case a 
single width will likely be desired and thus one state- 
ment width replaces 5. Table 4 and especially 12 show 
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several successful objects taking on the same properties 
in a compact script. 

Statement 50s corresponds to the object 50v shown in 
FIG. 2a and when executed will give object 50v the 
properties it displays in FIG. 2a. Statement 505 which 
assigns the current properties to an object also appears 
in Table 5. 

TABLE 5 



90 91 



92 



93 



94 



95 96 

I I I i I I I 

NEXTOBJ SHOW, "Bg fld id 1162", "NAME" -1 "14,59,181,75" 



The first word on the line 90 is a call for the NEX- 
TOBJ handler with the arguments 91, 92 and 93. and 
the comment 94, 95 and 96. The first argument 91 can be 
HIDE indicating that the object should be invisible, or 
SHOW indicating it should be visible. (It can also have 
the values ASIS which means don't change its visibility 
or TOGGLE which means invert its visibility, but these 
are not often used.) The second argument 92 is a unique 
identifier specifying the object to be assigned the prop- 
erties in target. HyperCard assigns unique identifiers to 
each object it creates and these are used here; other 
handles such as ORDER and NAME are not unique as 
they may be changed. The third argument 93 is the 
object's name. It appears as an argument for use in the 
to be described gene porting, but also serves as a useful 
command to identify the object in question. The two 
dashes 94 are HyperTalk's indication a comment fol- 
lows. The comment consists of the object number 95 
and the object's coordinates 96 in pixels at the time the 
gene script was created. 

NEXTOBJ copies the current properties saved in 
target to the specific object 92 making it visible as indi- 
cated by the first argument 91. NEXTOBJ treats the 
following objects as special: 

ORDER: The property order is a number from 1 to 
the number of buttons or fields and specifies the order in 
which the objects are layered on top of each other. 
Order is important as it specifies overlapping. Hyper- 
Card does not allow direct setting of the property or- 
der; however by outputting the objects in the order 
they appear, HyperCard does allow a mechanism to 
force a property to a desired order. NEXTOBJ forces 
the current object to have the number specified by the 
global NEXTOBJECTNUMBER which it starts at 1 
and increments every time it is executed. The display of 
fields and buttons on top of each other in FIGS. 2b, 3b 
and 4b indicate their ordering. Where one object over- 
laps another as 74v overlaps 87v in FIG. 4b, it indicates 
that the overlapping object has a lower value for the 
ORDER property than the overlapped object. The 
order changes between formats and in FIG. 2b, unlike 
FIG. 4b, the button 74v is overlapped by 87v. 

NAME: The name could be specified in the gene 
script but is not. If it were then if the user changes the 
name of an object in one format, that object will still 
have its old name in other formats. It seems more natu- 
ral for each object to have the same name in all its 



formats and so the propety name is not specified in the 
gene script format. 

SCRIPT: The object's script is not specified by the 
gene script for the same reason the NAME is not 
changed. If the user changes a script in one format (e.g. 
DIAL OUT), he probably means to have that change 
occur in all formats. 

VISIBLE: This is specified by the first argument 91. 
This lets the user edit HIDE to SHOW so translating 
10 the gene makes that object visible, or edit SHOW to 
HIDE to make it invisible. The VISIBLE property is 
output as an absolute, rather than a differential value 
because one normally wants to change the visibility of 
objects individually. 
15 TOP: HyperCard objects have properties that specify 
the location of an object, but it does not have properties 
that specify the distance an object is from the previous 
object. Since objects are frequently evenly spaced verti- 
cally or horizontally, such properties are desirable as 
20 they encode more efficient scripts to the extent that the 
distances between objects are regular. For this reasons 
the compiler does not output absolute values for loca- 
tions but differential values. For each object line 32 
specifies YDELTA, the Y distance in pixels the next 
25 object is from the previous object. YDELTA (and 
XDELTA) are zeroed by GENESTART. When the 
flow chart in FIG. 11 is explained the use of YDELTA 
(and XDELTA) will be made clear. 
LEFT: Similarly, the compiler outputs a XDELTA 
30 to specify a relative distance between objects. 

These properties were treated as special because Hy- 
perCard did not support them fully (ORDER), or be- 
cause it seemed to be the best way to implement the 
invention. Other choices may be as good or better. 
35 The script continues specifying objects 52s, 545, 56s, 
60s, 62s, 64s, and 66s with property or attribute change 
statements 28, 30 and 32 interspersed. At the end the 
GENEDONE statement does necessary cleanup it 
takes an argument HIDE or SHOW or ASIS which 
40 specifies what should be done with the objects whose 
visibility was not specified. Normally HIDE is used, as 
the unspecified object normally should be invisible. 
SHOW makes the unspecified objects visible, and ASIS 
leaves them with their current visibility. END TRANS- 
45 LATEFIELDS 8 terminates the handler. 

Visible And Invisible Object Specification 

Two possible script forms can be generated. The one 
shown in table 4 shows only those objects that are visi- 

50 ble. A second possibility is to specify all objects. The 
script of table 4 with the insertion of table 6 at location 
20 in Table 4 does this for the FIG. 2a format The 
advantage of specifying only visible objects is that the 
scripts are shorter and the invisible and presumably 

55 irrelevant objects do not appear. The advantage of 
specifying all objects is to provide a complete record of 
what is on the background and to allow finding and 
making hidden objects visible. 

TABLE 6 



set textalign of target to center — 28 

set style of target to rectangle — 28 

set width of target to 174 — 28 

set height of target to 64 — 28 

put 140 into XDELTA — 30 

put -133 into YDELTA— 32 

nextObj Hide, "bg fld id 1304", "Proto From" 

set textalign of target to left — 28 

set textsize of target to 10 — 28 



-10 "168,22,342,86" - 68s 
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TABLE 6-continued 

set style of target to scrolling — 28 
set width of target to 440 — 28 
set height of target to 97 — 28 
put 147 into XDELTA — 30 
put 176 into YDELTA— 32 

nextObj Hide, "bg fid id 1263", "Proto Letter" -12 "16,217,456,314" ~ 72s 



Table 7 specifies the handler that translates the prop- 
erties of the visible background buttons. It is similar to 10 
the TRANSLATEFIELDS handler. Statement 74s 
outputs the DIAL OUT button and statement 70s out- 
puts the DOWN button. 

TABLE 7 

on TRANSLATEBUTTONS — 2 
set visible of target to true — 18 

. . 18 

set icon of target to 30696 
set top of target to 76 — 18 
set left of target to 436— 18 
GeneStart "Btn" — 24 
nextObj Show, "bg btn id 1472", "DIAL OUT' -1 "477,52,512,83" — 74s 
set width of target to 37 — 28 
set height of target to 28 — 28 
set icon of target to 2730 — 28 
put 231 into YDELTA — 32 

nextObj Show, "Bkgnd btn id 1509", "DOWN" -2 "436,307,473,335" -- 70s 
[code from Figure 8c would be inserted here] — 20 
GeneDone Hide -Unspecified Objects Hide.Show or Asls — 36 
end TRANSLATEBUTTONS — 8 



theight and textstyle that control painting and these are 
specified in statements 40. Line 220 specifies whether 
the stack should be displayed in rack mode showing 
only the first line of each card as is taught in U.S. Pat. 
No. 4,736,308 or in full card mode. Statement 222 speci- 



Table 8 specifies the code that would be inserted to fies whether the stack should be locked so the use can 
specify the invisible button properties. The description view and navigate through just those cards which 
of this output is the same as for fields. match a search criteria as is taught in U.S. Pat. No. 

TABLE 8 

set style of target to roundRect — 28 
set width of target to 132 — 28 
set height of target to 22 — 28 
set showname of target to true — 28 
set icon of target to 0 — 28 
put -264 into XDELTA — 30 
put -234 into YDELTA— 32 

nextObj Hide, "Bkgnd btn id 1360", Print Label" -10 "172,73,304,95"— 76s 
set width of target to 153 — 28 
put 167 into XDELTA — 30 
put -52 into YDELTA — 32 

nextObj Hide, "Bkgnd btn id 1302", "Create Letter" -11 "339,21,492,43" - 
84s 

put 0 into XDELTA — 30 
put 30 into YDELTA — 32 

nextObj Hide, "Bkgnd btn id 1383", "Go Proto Letter" -12 ... — 86s 

nextObj Hide, "Bkgnd btn id 1518", "Print Letter" -13 ... — 87s 



Since it may be appropriate for different formats for 50 4,736,308. Statement 223 specifies the search criteria, 

different values for certain global and viewing vari- Statement 224 specifies whether the fields should be 

ables, a configuration script is compiled which saves zoomed to overlay the names in the background as is 

and restores these values. Table 9 shows the configura- taught in U.S. Pat. No. 4,736,308. Statement 226 speci- 

tion script for FIG. 2a. Several kinds of global variables fies whether or not the current field is zoomed as is 

might be saved in the configuration script. The script 55 taught in U.S. Pat. No. 4,486,857. Statement 228 speci- 

shown in table 9 contains the globals saved in the cur- fies the dimensions of the zoomed area. Statement 230 

rent implementation. Those that have numbered state- specifies the dimensions of the Zoom rack area which 

ments are briefly described here. HyperCard has global where the first line of each card is displayed when in 

paint properties called pattern, textfont, textsize tex- rack mode. 

TABLE 9 



on TRAN SL ATECONFIGURATION - 2 
GeneStart "Cnf — 24 

hrkSet "pattern","2" ~ Paint Pattern: Repaint & Retitle —40 

hrkSet "textfont'7'Geneva" - text font for: Repaint & Retitle —40 

hrkSet "textsize"/*12" - text size for: Repaint & Retitle —40 

hrkSet "textheight","16" - text height for: Repaint & Retitle —40 

hrkSet "textstyle", "bold" - Stack text style: Repaint & Retitle — 

40 

hrkSet "2Rack","false" - True means: V Zoom Rack — 220 



15 

TABLE 9-continued 
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hrkSet "FindLock","false" - 
hrkSei "FindCom","find"<S: quote &"mor"& 
&"ADDRESS2"& quote — 223 
hrkSet "ZNAMES","false" 
hrkSet "ZField", "false" 
hrkSet "ZFRect", "3 9, 84,493,287" 

228 

hrkSet "ZRRect","39,84,493,287" 

hrkSet "SortLock","false" 

hrkSet "Archivemode","false" — 

hrkSet "Cardld","11319" 

hrkSet "HrkSelFldId","1195" 

hrkSet "SortCom","sort text by fld"& quote 

hrkSet "Archivestack","" 

hrkSet "HRacksMode'7'true" 

hrkSet "DeltaX","10" 

hrkSet "DeltaY","8" 

hrkSet "ZRRect","-43,l 16,406,312" 

hrkSet "RackFldList","" 

hrkSet "ZNRect","0,0,0,0" 

hrkSet "ZFRect","39,84,493,287" 

hrkSet "PaintRect","0,0,5,l 1,341" 

hrkSet "Marbling","" 

GeneDone Hide -Unspecified Objects Hide, 
end TRANSLATECONFIGURATION - 8 



True means: V Find Lock - 
quote &"in bg fld"& quote 



-222 



True means: V Zoom Names —224 
True means: V Zoom Field — 226 
Window Rectangle for: Zoom Field • 



230 



Window Rectangle for: Zoom Rack 
True means: V Sort Lock 
True means: V Archive Cards 
ID of card to to go to: empty = none 
ID of Current Field: empty = none 
&"NAME"& quote &"" 
Stack for cut & deleted cards 
True means: V HyperRacks 
Maximum X-Axis adjust for Tile Fields 
Maximum Y-Axis adjust for Tile Fields 
Window Rectangle for: Zoom Rack 
Fids in Rack: Zoom Rack 
Window Rectangle for: Zoom Names 
Window Rectangle for: Zoom Field 
Rectangle of area repainted: Paint & Tile 
List of marbling commands: LDIT 
Show or Asls — 36 



In Table 9 the statements 2, 24, 36 and 8 are the begin- 
ning and ending statements discussed earlier. The state- 25 
ments labeled 40 such as the one in table 10 specify the 
globals: 

TABLE 10 

hrkSet "textfont","Geneva" 



button script. Table 11 shows the gene script which 
translates into the properties of the visible buttons 
shown in FIG. 3a. The button PRINT LABEL is speci- 
fied in statement 765. This was invisible in format 2a. 



Stack text font for: Repaint & Retitle —40 



Here HRKSET sets the global variable specified by The DIAL OUT button 74 does not appear as it is 
its first argument, in this case "textfont" to one specified invisible but the button DOWN 70s appears in script as 
by its second one "geneva". it appears in the format 3a as DOWN button 70v. 

TABLE 11 

on TRANSLATEBUTTONS — 2 
set visible of target to true — 18 
... — 18 

set icon of target to 0 — 18 
set top of target to 73 — 18 
set left of target to 172 — 18 
GeneStart "Btn" — 24 

nextObj Show, "bg btn id 1360", "Print Label" -1 "332,50,432,72" — 76s 

set style of target to opaque — 28 

set width of target to 35 — 28 

set height of target to 31 — 28 

set showname of target to false — 28 

set icon of target to 2730 — 28 

put 265 into XDELTA — 30 

put 235 into YDELTA — 32 

nextObj Show, "Bkgnd btn id 1509", "DOWN" -2 "437,308,472,339" —70s 
GeneDone Hide -Unspecified Objects Hide,Show or Asls — 36 
end TRANSLATEBUTTONS — 8 



A Second Format 

If the user changes the properties of objects from that 
shown in FIG. 2a to that shown in FIG. 3a and does a 
KEEP BKGND FORMAT, he will get a different gene 



Table 12 shows the gene script which translates the 
properties of the visible fields into the format shown in 
FIG. 3a. This specifies only the fields that shown in 
format 3a. 



TABLE 12 

on TRANSLATEFIELDS - 2 
set visible of target to true — 18 
... — 18 

set height of target to 23 — 18 
set top of target to 1 17 — 28 
set left of target to 129 — 28 
GeneStart "Fid" — 24 

nextObj Show, "bg Hd id 1162", "NAME" -1 "279,117,503,140" — 50s 
put 0 into XDELTA— 30 
put 25 into YDELTA— 32 

nextObj Show, "bg Hd id 1196", "TITLE " -2 "279,142,503,165" - 56s 
nextObj Show, "bg fid id 1197", "COMPANY" -3 "279,167,503,190" — 54s 
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TABLE 12-continued 

nextObj Show, "bg fld id 1198", "ADDRESS1" —4 "279,192,503,215" 58s 
set textsize of target to 10 — 28 
set width of target to 137 — 28 

nextObj Show, "bg fid id 1199", "ADDRESS2" -5 "279,217,439,240" — 60s 
set width of target to 89 — 28 
put 135 into XDELTA — 30 
put 0 into YDELTA— 32 

nextObj Show, "bg fld id 1366", "Zip" -6 "439,217,503,240" - 62s 
GeneDone Hide -Unspecified Objects Hide,Show or Asls — 36 
end TRANSLATEFIELDS — 8 



Flow Charts 

FIG. 8 shows a flow chart describing how KEEP 
BACKGROUND FORMAT works. The first state- 
ment 102 creates a card in the stack and copies the 
background picture and pastes it on that card. It then 
puts that card's identifier into the global GENEPIC- 
TID 103 for use in creating the GENEINFO hander. 
Next it outputs the handler GENEINFO 104. The com- 
pilation of this handler whose output is displayed in 
Table 2 is straightforward. Next the handler TRANS- 
LATEGENE which actually does the work of rever- 
sion and is shown in table 3 is output. Following this the 
handlers for translating buttons 108, translating fields 
110 and translating the configuration 112 are output. 

The routine COMPILEHANDLER whose flow- 
chart is in FIG. 9 is called to output TRAN- 
SLATEBUTTON or TRANSLATEFIELD. It com- 
piles handlers like those in Table 4, 6, 7, 8, 11, and 12. 
First it orders the objects of type objtype 116. This step 
is not necessary and might be a user option. While there 
are many ways to order objects, ordering them from the 
upper left hand portion of the screen down to the lower 
right hand portion is the method used. If the objects are 
not ordered the second object might be down 40 pixels 
form the first, and the third object up 20 from the sec- 
ond. It makes the scripts simpler and editing them easier 
if the second and third objects are reversed so that the 
new second object is 20 down from the first, and the 
new third 20 down from the second. The problem is 
probably not solvable in the optimal case, but an opti- 
mal solution is not required. All that is desirable is for 
ORDER OBJECTS to make a reasonable guess as to a 
good order to keep scripts short and facilitate their 
editing. As part of ordering the objects the invisible 
objects are normally ordered at the end. 

Next the compiler outputs "On TRANSLATE- 
FIELD" (or ON TRANSLATEBUTTON) at line 118; 
this compiles the statement 2 in Table 4. Next all the 
properties the first object is to have are outputted at line 
119; this compiles the statements 18 in table 4. Next 
GENESTART is output 120; this compiles statement 
24. Now it prepares to loop though all the objects of 
type OBJTYPE by setting the object index to 1 at line 
122. In the loop it first compiles a NEXTOBJ statement 
124. In table 4 as an example, the first time through the 
loop it would compile statement 50$, then next time 52s 
etc. Next it checks to see if the last object has been 
output at line 126. If there are still objects to output it 
increments the object number at line 127. the next box 
and inner loop at line 128 checks to see if this is an 
invisible object that should not be output. If only visible 
objects are to be output and the object i is invisible it 
loops back to line 126. 

In lines 130, 131 and 132 the statements 28 which 
specify changes in properties from one object to an- 
other are compiled. Only two property are specifically 



referred to in lines 130 and 132 the other properties 
being suggested by line 131. Line 130 checks to see if 
the width of object is the same as the current target 
width. Only if it is different does it compile a statement 
of the form 28 in table 4. Next all other properties that 
are differentially specified are similarly compiled in 
statements 131 and 132. Some special special properties 
such as order, visible, name, script, left and top may not 
be differentially specified. 

Each property is checked to see if it is changed and if 
it has, the process is repeated. Then it loops back to 
compile the next object 124. 

When all the objects have been compiled control 
goes from box 126 to box 134. This compiles a GENE- 
DONE 134 and END TRANSLATEFILED or END 
TRANSLATEBUTTON 135. 

It should be understood that while the description 
here describes the compilation process as distinct from 
the graphical editing process, they could occur at the 
simultaneously. As changes are made in the format 
using HyperCard on the screen, the system could main- 
tain a gene script which defines its specifications and 
modify that script incrementally. 

When the user executes a gene button script it trans- 
lates the gene into its format. Except for the handler 
NEXTOBJ most of the script should be straightforward 
to understand. FIG. 10 shows how NEXTOBJ works. 
First it adds DELTAY to the top of the target 136 and 
DELTAX to the left of the target. 

Next it checks to see if the object OBJECT ID actu- 
ally exists at line 140. It may not as it could have been 
deleted since the gene was made. If it doesn't exist it 
might generate a soft error but then exit. It is important 
that this test occur after 136 and 138 so the next object 
will be placed where it was rather than where this ob- 
ject would be. Next it sets the objects visibility to that 
specified by its first argument 142. Next it sets each 
property (except order, name, and script) to the value 
that object has in target 148-153. Finally it sets the 
object's order to NEXTOBJNO 153 which was initial- 
ized to 1 and increments NEXTOBJNO 155 and is 
finished 

Porting to Other Stacks 

HyperCard provides a mechanism to copy gene but- 
tons from one stack to another. Thus a gene button can 
be created in one stack and copied to and pasted on 
another. Such a gene button cannot be used on the 
destination stack without changes to the scripts to refer 
to objects in the destination stack in place of objects in 
the source stack. Once a gene button is copied to an- 
other stack it can be used one of two ways: 

(a) Parts of its script can be copied into a gene button 
that was created on the destination stack. Typically 
initial property specifications such as 18 in table 4 might 



5,228,123 

19 20 

be copied to override initial specifications in the destina- The converted and installed script for use in the origi- 

tion stack. The genetic analogy here is recombination. nal name and address stack is shown in table 14 and its 

(b) The genes can be installed in the new stack. It can graphical representation is shown in FIG. 6. FIG. 6 

be detected as foreign because GENEINFO in table 2 differs from FIG. 5 in that 50v displays the name and 52v 

specifies the different source stack it was created on. An 5 displays the company that appear in FIGS. 2 through 5. 

attempt to translate a gene on a foreign stack produces The format shown in FIG. 5 has been ported to the 

an INSTALL ME menu. original name and address stack. A new field 79 has 

An example of what installing a gene in a new stack been cloned from field 775 in FIG. 5 and background 

means is provided in FIGS. 5, 6, la and lb and its pro- button 81v has been cloned from 71v shown in FIG. 5. 

cess is shown in the flowchart in Table 11. FIG. 5 shows 10 The converted gene script for translating the field for- 

a different stack, stack B with all its fields and buttons mats shown in FIG. 6 is shown in table 14. 

TABLE 14 



on TRAN SL ATEFIELDS 

set visible of target to true — 1 8 

set top of target to 50 — 18 
set left of target to 40 — 18 
GeneStart "Fid" — 24 

nextObj Show,"Bkgnd fld id 1162", "Name" -1 "40,50,216,77" —50s 
set width of target to 315 28 
set height of target to 25 — 28 
put -131 into XDELTA —30 
put 51 into YDELTA —32 

nextObj Show,"Bkgnd fid id 1197", "Firm" -2 "216,50,465,78"- 52s 

set textalign of target to center — 28 

set width of target to 315 — 28 

set height of target to 25 — 28 

put -131 into XDELTA —30 

put 5 into YDELTA —32 

nextObj Show,"Bkgnd fid id 1528", "Social Security Number" -3 . . . — 79s 
GeneDone Hide -Unspecified Objects Hide,Show or Asls 
end TRANSL ATEFIELDS 
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showing. Stack B has three background fields NAME 
735, FIRM 755 and SOCIAL SECURITY NUMBER 
775 and one background button CHECK VALIDITY 
OF SOCIAL SECURITY NUMBER 715. Such a stack 
could be developed to keep social security numbers and 
check them for validity, or it could be used to provide 
an application to be ported to and installed in another 
stack. Stack A shown in FIG. 2a has a field named 
NAME 50v which (we assume) has the same function as 
73v, and a company 52v which has the same function as 
Firm 75v. It however has no SOCIAL SECURITY 
NUMBER 77v field and no CHECK VALID SS NO 
field 71v. 

Installing the gene requires searching the gene 
scripted and any cloned buttons for references to source 45 
stack objects and replacing them with references to the 
appropriate objects on the destination stack. The gene 
script for stack B shown in FIG. 5 is shown in table 13. 

TABLE 13 

on TRANSLATEFIELDS 

set visible of target to true — 18 

set width of target to 50—18 
set height of target to 40 — 18 
GeneStart "Fid" - 24 
nextObj Show, "Bkgnd fid id 2" 
set width of target to 249 — 28 
set height of target to 28 — 28 
put 176 into XDELTA —30 
nextObj Show, "Bkgnd fid id 1" 
set textalign of target to center - 
set width of target to 315 — 28 
set height of target to 25 — 28 
put -131 into XDELTA —30 
put 51 into YDELTA —32 

nextObj Show,"Bkgnd fid id 3", "Social Security Number" -3 . 
GeneDone Hide -Unspecified Objects Hide,Show or Asls 
end TRANSLATEFIELDS 



A review of the scripts in tables 13 and 14 shows that 
3 substitutions have been made. Line 73s has been re- 
placed with line 50s replacing Bkgnd Fid id 1 with 
Bkgnd fid id 1162 reflecting the change in the identifica- 
tion numbers for the NAME field in the two stacks; 
second, line 15s has been replaced with line 52s replac- 
ing Bkgnd Fid id 1 with Bkgnd Field ID 1197 reflecting 
the different identification number for the FIRM- 
/COMPANY field in the two stacks; third, line 77s has 
been replaced with line 79s replacing Bkgnd Fid id 3 
with Bkgnd Fid id 1528 specifying a new SOCIAL 
SECURITY background field which was cloned from 
the source stack shown in FIG. 5. 

Similar substitutions were made in the TRAN- 
SLATEBUTTONS. Table 15 shows the TRANS- 
LATE BUTTONS handler in for the format shown in 
FIG. 5 for stack B, and Table 16 shows the translated 
handler as is displayed in FIG. 6 for stack A. A review 
of these scripts will show that line 71s has been changed 



"Name" -1 "40,50,216,77" — 73s 



"Firm" -2 
■28 



•216,50,465,78" -75s 



-77s 
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from specifying the "Bg btn id 4" in stack B to "Bg btn contains "NEXTOBJ" which would specify an object 
id 1527" in stack A. to be output at 160. If not, it loops to box 178 which 

TABLE 15 

on TRANSLATEBUTTONS ~ 
set visible of target to true --- 1 8 

set icon of target to 0 — 18 
set top of target to 174 — 18 
set left of target to 167 — 18 
GeneStart "Btn" - 24 

nextObj Show t "Bg btn id 4", "Check Valid SS No." --1 "167,174,349,198" - 

71s 

GeneDone Hide -Unspecified Objects Hide.Show or Asls 
end TRANSLATEBUTTONS 



TABLE 16 

on TRANSLATEBUTTONS 

set visible of target to true — 18 
... — 18 

set icon of target to 0 — 18 
set top of target to 174 — 18 
set left of target to 167 — 18 
GeneStart "Btn" - 24 

ne.xtObj Show\"Bg btn id 1527", "Check Valid SS No."-. . . 81s 
GeneDone Hide -Unspecified Objects Hide,Show or Asls 
end TRANSLATEBUTTONS 



The original CHECK VALID SS NO button 71v 
script is shown in table 17. 

TABLE 17 

on mouseUp 30 
put line 1 of bkgnd fid id 3 into no — 200 

end mouseUp 



The CHECK VALID SS NO button script 81 v as 35 
ported to the stack A is shown in table 18. 

TABLE 18 



on mouseUp 

put line 1 of bkgnd fid id 1609 into no —202 

end mouseUp 
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Here "bkgnd fid id 3" at 200 in table 17 is replaced 
with bkgnd fid id 1609 at 202 in table 18. 

Installing the gene for the format of stack B shown in 45 
FIG. 6 into stack A shown in FIG. 5 consists of copying 
the gene, pasting it and installing it. This will cause the 
script in table 13 for stack B to be changed to the script 
in table 14 for stack A and the script in table 17 for stack 
B to be changed to the script in table 18 for stack A. 50 

The flowchart in FIG. 11 shows how this occurs. 
The installation process constructs two lists. One is 
called PAIRLIST and consists up a list of pairs of cur- 
rent, source stack (e.g. B) IDs and new destination stack 
(e.g. A) IDs. The format could be: (al, bl),(a2, b2), ... 55 
). CLONELIST is a list of all of the objects (such as 
SOCIAL SECURITY NO.) that are cloned from the 
source stack to the object stack. To convert a button, 
gene or other script from its source stack form to its 
destination stack form, all source stack object identifiers 60 
(al, a2 . . . ) are replaced with the corresponding desti- 
nation stack identifiers (bl, b2 . . . ). 

When a user selects an uninstalled gene, it presents 
him with a limited menu which includes INSTALL ME 
Selecting INSTALL ME initiates the procedure shown 65 
in the flow chart in FIG. 11. First at 157, PAIRLIST is 
set to empty. Next the program loops through each line 
of the genes script at 158, For each line it asks if it 



increments the scripts line number. Otherwise it sets 
SRCID to the ID of the object NEXTOBJ would trans- 
late at 162, as indicated at 92 in table 5. Next the user is 
presented with four options as to what to do with that 
object referenced in the gene script at 164. The options 
are: 

CLONE the object 168: The object is copied from 
the source stack to the destination stack, complete with 
script and name. 79v in FIG. 6 stack A was cloned from 
77v in FIG. 5 stack B; and 81v in FIG. 6 was cloned 
from 71 v in FIG. 5. (The script changes for these for- 
mats are shown in tables 13 and 14). The id HyperCard 
gives the destination stack object is put in DESTID 170. 
Next DESTID is appended to PORTLIST so its script 
can be converted to the destination stack object identi- 
fiers 171. From here control rejoins the other three 
options at 177. 

USENAME: this option only occurs if there exists an 
object in the destination stack with the same name as the 
object in the source stack 172. The object's name ap- 
pears in the NEXTOBJ statement as shown in 93 in 
table 5. If the user chooses this option, DESTID is set to 
the id of the object in the destination stack that has that 
name in the source stack. An example of this is the 
object NAME, 73v in FIG. 5 which was converted to 
50v in FIG. 6. Control resumes at 177. 

FINDNAME: this option lets the user select a desti- 
nation stack object to use at 174. The user could specify 
the object by id, name or the program could prompt the 
user. The id of whatever object is chosen is put in DES- 
TID. An example is FIRM 75v in FIG. 5 which is re- 
placed by COMPANY 52v in FIG. 6. Control resumes 
at 177. 

IGNORE: This option is used if the user does not 
want to use to the object 176. If NEXTOBJ has a non- 
existent object as an argument it behaves as if it was not 
called (except to give a soft error). Control resumes at 
177. 

The above four options are joined at 177 where the 
new pair SRCID and DESTID are added to PAIRL- 
IST. 
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Next the scripts line number is incremented at 178. If TRANSLATE BUTTONS translates the button 
it is not the last line, control goes back to the beginning properties by executing the TRANSLATEBUTTONS 
of the loop 158. If it is the last line in the script, RE- handler. 

PLACEIDS 178 uses the list CLONELIST to replace TRANSLATE PICTURE translates to the saved 
all references to the source stack objects with refer- 5 background picture specified by GENEPICTID. 
ences to just determined destination stack equivalents. TRANSLATE CONFIGURATION translates to 
It does this in the gene script and all the scripts in the saved global configuration variables. 
PAIRLIST. ~ COPY GENE copies the gene button to a buffer 

Once the user has ported a format to a new stack as from which it can be pasted to another stack. (It is just 
from FIG. 5 to FIG. 6, he can use it as is. To integrate 10 HyperCard's Copy button command.) 
the ported function into the destination stack the user CLONE ME makes a copy of itself and asks for a 
can name.-This is the mechanism to save multiple formats as 

a) Translate the stack to the format 2a. This will of the present implementation of KEEP BACK- 
course make the button 81v and and field 79v invisi- GROUND FORMAT puts the gene in TRAN- 
ble, 15 SLATEBKGND, rather than asking the user for a 

b) Make the ported objects visible either (a) by using name of a gene to store it in. 

HyperTalk commands, or creating a new gene script EDIT ME lets the user edit the gene script, 
for the FIG. 2a format which shows invisible objects, The normal operation is for the user to create a back- 
editing the 81 v and 79v to make them visible, and ground format, then use the KEEP BACKGROUND 
translating the script. The result is displayed in FIG. 20 FORMAT COMMAND to save it on the gene button 
la. TR AN SLATEBKGND, and then to select that button 

c) Edit the background using HyperCard commands to and use the CLONE ME command to make a named 
make a more finished presentation. The result is copy. As the user repeatedly does this, he will build up 
shown in FIG. lb. a library of different genes for different formats and by 

25 selecting any one and executing the TRANSLATE 
Card Formats GENE COMMAND he can translate to that format. 

As described in the beginning, HyperCard cards can A menu called FORMAT menu has been added to 
have formats with their own buttons, fields and pic- HyperCard's menu bar and lists all of the background 
tures. The capability described here is equally applica- genes. This is more natural for use as a finished applica- 
ble to support cards involving the same methodology. 30 tions than is gene selection. If each gene specifies an 
Porting formats from one card to another is no different application, then the format menu is an application 
than porting from one stack to another. Similarly for- selector for that stack. 

mats can be ported from cards to stacks or from stacks In normal operation the user will modify the back- 
to cards, ground objects, do KEEP BACKGROUND FOR- 

ATTnw 35 MAT commands followed by editing the saved gene 

Mb 1 HOD Uh OrbKA I ION scrjpt folIowed by translating it. Often the user will 

The system appears as 5 menu items added to Hyper- cycle through this process two or three times until a 
Card's menu bar and as a gene buttons 88 with a graphi- format proves acceptable and he will then use a 
cal image that identifies them as gene buttons. These CLONE ME command to give it a name and save it. 
gene buttons appear on the surface of the card or back- 40 Much of the power of the invention comes from the 
ground and contain the gene scripts for creating the multiplicity of tasks it is useful for. Here we separate its 
formats. Gene buttons are shown at 88 in FIG. 2c. uses into three categories: (a) as a single format system, 

The five menu items are: (b) as a multiple format system for a single stack and (c) 

KEEP BACKGROUND FORMAT complies a as a mechanism to port formats from one stack to an- 
gene script into a background gene button called 45 other. As a single format system 
TRANSLATEBKGND. This is what was described in The user can KEEP BACKGROUND FORMAT 
detail here. and then change the format. But translating the gene he 

TRANSLATE BACKGROUND FORMAT trans- restores the original format, 
lates the gene button TRANSLATEBKGND. This 1. This provides an UNDO capability, letting the user 
translates the most recently saved background format. 50 try (but not save) new formats undo changes he made. 

KEEP CARD FORMAT complies a gene script into 2. This lets the user modify the format in a script form 
a card gene button called TRANSLATECARD. as well as a visual image form. While the visual image 

TRANSLATE CARD FORMAT translates the form us usually better for gross layout, a script form is 
gene button TRANSLATECARD. This translates the often better for fine tuning the image. Some properties 
most recently saved card format. 55 (e.g. visible) cannot be changed graphically and the 

SHOW GENES toggles the display of the gene but- script provides a means for making the values of these 
tons 88 on and off between the formats shown in FIG. properties visible and for changing those properties. 
2a and FIG. 2c. When creating and modifying genes, it While it is always possible to write from scratch a script 
is useful to have the gene buttons visible; but they are that will do what the user wants, this requires both 
best left off in normal use. 60 effort and knowledge. The ability to automatically get a 

If the user selects a gene with a mouse and depresses script that is close to what the user wants is valuable as 
the mouse button, he will be presented with a menu of a much large number of people are likely to be able to 
options: recognize what is not right and fix it, then would be able 

TRANSLATE GENE translates the gene so its for- to write a program in the first place, 
mat is realized on the screen. It calls the handlers to 65 3. Often objects get too small, are invisible or go off 
translate the fields, buttons, picture and configuration. screen, and are difficult to find. The gene script makes 

TRANSLATE FIELDS translates the field proper- it easy to find them. 4. The script is compiled to specify 
ties by executing the TRANSLATEFIELDS handler. . only property differences. This has the advantage that 
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user can often make global changes by changing a single (b) Edit genetic material from one stacks gene to 

word. Graphical editing makes it difficult to create another. This is often useful if the major changes are to 

uniform buttons and fields— ones with the same dimen- global parameters or a few objects, 

sions spaced evenly apart, but editing a gene script to c) Insert a new handler to intercept GENESTART 

delete program statements which specify the slightly 5 and redefine the initial parameters. This is particularly 

different properties both simplifies the script and makes useful in giving a similar look to a large number of 

the graphical form uniform when the gene is translated. cards. 

4. Often a stack may originate with a person or orga- 

As Multiple Gene Formats nization and be used to several other persons, if each 

The ability to save alternative formats in gene scripts 10 person makes his own modifications to his version of 

allows the user to switch between different formats for the stack, are two potential problems exist which are 

the same stack. This is useful for: solved by the gene metaphor: 

1. Building and testing different user interfaces to see T * e originator wants to distributed a new version 
which is best. In the simplest form the interfaces differ that contains new functional capability and users want 
in only the arrangement of the buttons. However, 15 to install it in his own stack and yet still be able to keep 
where interfaces differ in just some of their capability, his own custom buttons, script and format: In this case 
the gene metaphor naturally supports both the common the user can insta11 the new 8 ene t0 S et th 9 ne ^ format 
parts and unique part of the applications. and sti11 translate to his existing formats Furthermore, 

2. Different formats can be geared to different skill the " s f r . can CT ™ ie new formats cor ? bim : tlu : 
levels of users. Typically novice formats will have 20 capabilities m the custom genes with those of updated 
fewer visible objects and applications and might have P 0 *^! ? ene fo f in ? t ;. , , . , „ J , - 
more helpful application scripts, while expert formats , \ lf * e newl * f hvered «"* * an ?^ data b f e 
would have more visible objects, more applications, and (rathe ! than functional capability), but the user has 
less unwanted help in executing the application. , € f ecial cus * m formats ' the user Can port hlS CUSt0m 

3. Different formats can implement very different 25 formats to the new stack. 

applications built on the same data base. For example a CONCLUSION RAMIFICATIONS AND SCOPE 

name and address stack might have a phone and address OF THE INVENTION 

format, a print label format and a mail merge format. By Whi]e Ms invenXion is describ ed in the context of 

switching between these different formats the user 3Q HyperCard because it is implemented there and Hyper- 

switches between applications. Card k ^ available> hs use is much broader than 

4. Users and developers can keep genes for earlier that It can be used in any tem consisting of compo . 
versions of applications and add new objects or copy nents that have ft visual re p reS entation where it is desir- 
and modify exiting ones to created updated versions. able tQ view different arrangements of different compo- 
This allows the users and developers to enter the risky 35 nent subse t s 

area of change with the ability to translate to earlier While the invention uses the concept of program 

versions. scripts as part of object buttons, these scripts could just 

(a) It lets users add new buttons and fields without as easiIy be macros of a series of keystroke actions or as 
worrying about their effect on existing formats. With G f m enus. 

conventional methods, the developer would have to go 40 What is claimed is: 

into the existing programs, understand them and modify x In a computing device, including a display device 

them to add the new capability with the real possibility capable of displaying a plurality of objects at one time, 

of creating bugs. Here, the user just reformats the stack an mput device, a data storage device for storing data, a 

and adds any needed new buttons (with their applica- processor responsive to said input device for accepting 

tion scripts) and fields and saves the new format. 45 data and also responsive to stored programs, the im- 

(b) If the user does not modify existing scripts but provement comprising: 

only adds new ones then if new format's application fi rst program means for controlling the visual appear- 

proves buggy, the user can translate to an old format ance of an object on the display device, the object 

which should work as before. having associated therewith a first set of attributes, 

Multiple Stack Uses 50 sa * d ** rst set °^ attributes defining the appearance of 

P said object; 

Users can copy gene buttons from one stack to an- means for selecting said object and thereby executing 

other (or one card to another, or between cards and a program unique to said object; 

stacks): second program means for selectively storing in a 

1. Users can Copy formats from one stack and install 55 first location of said data storage device the first set 
or inject them into another stack. This could be used to of attributes associated with said object; 

copy a label printer, dial out, or other more complex first input means responsive to commands from said 

script from one stack to another. input device for changing at least one attribute of 

2. Users can create hybrid formats consisting of parts the first set of attributes to form a second set of 
of different stack formats, some of which have been 60 attributes whereby the visual appearance of said 
imported from other stacks. object is changed; 

3. Porting genes to other stacks is a way to synchro- third program means for selectively storing in a sec- 
nize formats. If a user has many stacks or cards should ond location in said data storage device the second 
have the same format the gene metaphor provides three set of attributes associated with said object; and, 
methods for doing it: 65 second input means for translating said object to the 

(a) Port genes to the new stack. This works best visual appearance obtained with said first set of 

where most of the objects in the source stack have attributes, said second input means responsive to 

analogies in the destination stack. said input device and said first set of attributes 
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stored in said first location of said data storage 
device whereby by a simple input command re- 
store a previous set of attributes. 

2. The device of claim 1 wherein the first set of attri- 
butes further defines the location of said object on said 5 
display device. 

3. The device of claim 1 wherein the first set of attri- 
butes further defines whether the said object will be 
visually apparent on said display device. 

4. The device of claim 1 wherein the second program 10 
means includes means to edit the said object graphi- 
cally. 

5. The device of claim 1 wherein the second program 
means includes means to modify the first set of attri- 
butes in the first program means. 15 

6. In a computing device, including a display device 
capable of displaying a plurality of objects at one time, 
an input device, a data storage device for storing data, a 
processor responsive to said input device for accepting 
data and also responsive to stored programs, the im- 20 
provement comprising: 

means for selecting said object and thereby executing 
a program unique to said object; 

first program means for simultaneously controlling 
the visual appearance of several objects in a first 25 
arrangement on the display device each of the 
objects having associated therewith a unique first 
set of attributes, said unique first set of attributes 
defining the appearance of said object; 

second program means for selectively storing in a 30 
first location of said data storage device the unique 
first set of attributes associated with each of said 
objects; 

first input means responsive to commands for said 
input device for changing at least one attribute of 35 
the unique first set of attributes of at least one ob- 
ject to form a second set of attributes whereby the 
visual appearance of said at least one object is 
changed to a second arrangement; 

third program means for selectively storing in a dif- 40 
ferent location of said data storage device the sec- 
ond set of attributes associated with said at least 
one object and for storing the unchanged unique 
first set of attributes in conjunction with the second 
set of attributes and, 45 

second input means for translating the said at least 
one object to the visual appearance obtained with 
said unique first set of attributes said means respon- 
sive to said input device and said first set of attri- 
butes stored in said first location of said data stor- 50 
age device. 

7. The improvement of claim 6 wherein the unique 
first set of attributes further determines the locations of 
said objects on said display device. 

8. The improvement of claim 7 wherein the unique set 55 
of attributes determining the location of a first object on 
said display device is defined relative to a predeter- 
mined position on said display device, and further 
wherein the unique set of attributes determining the 
location of a second object on said display device is 60 
defined relative to said first object, and 

means to edit said second program means such that if 
an attribute of two successive objects have the 
same value the second object is not presented for 
editing. 65 

9. The improvement of claim 6 further including 
means for copying the second set of attributes and the 
unchanged first set of attributes, 



and further wherein said first program means con- 
trols the visual display of said objects in said sec- 
ond arrangement in accord with said second set of 
attributes and in conjunction with said first set of 
attributes. 

10. The improvement of claim 9 further including 
means for indicating on each of said first and second 
arrangement the presence of two sets of attributes for 
defining the visual appearance of said objects in either 
of said first or said second arrangement. 

11. The improvement of claim 10 wherein each of 
said objects has associated with its first and second set 
of attributes an identifier; the improvement including 
name means for simultaneously changing said identifier 
associated with both said first and second set of attri- 
butes upon changing the identifier associated with one 
of said sets of attributes by commands received from 
said first input device. 

12. The improvement of claim 6 wherein the unique 
first set of attributes further defines whether said object 
will be visually apparent on said display device. 

13. The improvement of claim 12 wherein the unique 
first set of attributes further determines the locations of 
said objects on said display device. 

14. The improvement of claim 13 wherein the unique 
set of attributes determining the location of the first 
object on a display device is defined relative to a prede- 
termined position on said device, and further where the 
unique set of attributes determining the location of a 
second object on said display device is defined relative 
to said first object, and 

means to edit said second means such that if an attri- 
bute of two successive objects have the same value 
the second object is not presented for editing. 

15. The improvement of claim 14 further including 
means for copying the second set of attributes and the 
unchanged first set of attributes, 

and further wherein said first program means will 
control the visual display of said objects in said 
second arrangement in accord with said second set 
of attributes and in conjunction with said first set of 
attributes. 

16. The improvement of claim 15 further including 
means for indicating on each of said first and second 
arrangements the presence of two sets of attributes for 
defining the visual appearance of said objects in either 
of said first or said second arrangements. 

17. A computing system for simultaneously control- 
ling the display of a plurality of objects on a display 
device, the system comprising: 

a display device; 
an input device; 
a data storage device; 

a processor responsive to said input device for ac- 
cepting data and further responsive to store pro- 
gram; 

means for selecting said object and thereby executing 
a program unique to said object; 

first program means for simultaneously controlling 
the visual appearance of several objects on a first 
arrangement on the display device each of the 
objects having associated therewith a unique first 
set of attributes, said unique first set of attributes 
defining the appearance of each of said objects; 

second program means for selectively storing in a 
first location of said data storage device the unique 
first set of attributes associated with each of said 
objects; 



first input means responsive to commands from said 
input device for changing at least one attribute of 
the unique first set of attributes of at least one ob- 
ject to form a second set of attributes whereby the 
visual appearance of said at least one object is 5 
changed to a second arrangement; 

third program means for selectively storing in a sec- 
ond location of said storage device the second set 
of attributes associated with said at least one object 
and for storing the unchanged unique first set of 
attributes in conjunction with the second set of 
attributes; and, 

second input means responsive to said input device 
for translating the said at least one object to the 15 
visual appearance obtained with said unique first 
set of attributes. 

18. The improvement of claim 17 wherein the unique 
first set of attributes further determines the locations of 
said objects on said display device. 20 
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19. The improvement of claim 18 wherein the unique 
set of attributes determining the location of a first object 
on a display device is defined relative to a predeter- 
mined position on said device and further wherein the 
unique set of attributes determining the location of a 
second object on said display device is defined relative 
to said first object, and 

means to edit said second program means such that if 
an attribute of two successive objects have the 
same value the second object is not presented for 
editing. 

20. .The improvement of claim 18 further including 
means for copying the second set of attributes and the 
unchanged first set of attributes, 

and further wherein said first program means will 
control the visual display of said objects in said 
second arrangement in accord with said second set 
of attributes in conjunction with said first set of 
attributes. 
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